對 Agent 承諾「可用性」是什麼意思

傳統服務的 SLA 相對單純：服務有沒有回應、回應時間多長。Agent 服務複雜在於——它可能「有回應」但「沒幫上忙」。如果 Agent 每次都在 500ms 內回覆「抱歉我無法處理這個問題」，技術上可用性是 100%，但這個承諾顯然沒有意義。

三層 SLO 設計

第一層：技術可用性。 服務有沒有回應、錯誤率多少。這層跟傳統服務一樣，是基本盤。

第二層：效能。 延遲的 P95／P99。呼應 Day 16 的提醒，別用平均值定 SLO，因為它會掩蓋長尾問題。

第三層：任務品質。 這是 Agent 特有的，也是最有價值但最難定的一層——例如「任務成功率不低於 X%」「人工介入率不超過 Y%」。

定義任務品質 SLO 的三個原則

原則一：定義要可量測，且雙方認可。 Day 20 提過「成功」的定義問題。如果 SLO 寫「任務成功率 90%」，但服務提供方跟使用方對「成功」的認定不同，這個 SLO 沒有意義。

原則二：從觀察開始，而非從期望開始。 先量測現況是多少，再決定承諾多少。直接承諾一個從沒達到過的數字，只會讓 SLO 變成形式。

原則三：留錯誤預算的空間。 SLO 不該定成 100%——那代表任何一次失敗都是違約，會逼團隊過度保守。合理的 SLO 應該留有錯誤預算（error budget），讓團隊在預算內可以承擔創新的風險。

錯誤預算怎麼用在 Agent 場景

錯誤預算的概念在 Agent 場景特別有用：假設 SLO 是任務成功率 90%，那就有 10% 的錯誤預算。當預算還充裕時，團隊可以更積極地嘗試新的 Prompt、新的模型版本、新的工具；當預算快用完時，就該凍結變更、專注穩定性。這給了「要不要現在升級模型版本」這類決策一個客觀的判斷依據，而不是靠直覺爭論。

這篇的檢查清單

• [ ] SLO 是否涵蓋技術可用性、效能、任務品質三層，而非只有前兩層？
• [ ] 任務品質的定義是否可量測且服務雙方認可？
• [ ] SLO 數字是否基於實際觀察，並保留合理的錯誤預算？

💡 關於作者 我是 Fngi，專注在 AI 安全與雲端資安領域。如果這篇對你有幫助，歡迎追蹤 Instagram @aid3fend，我在那裡分享更多 AI 資安的實務筆記與趨勢觀察。